Rather than making the Endpoint fully optional, could we make it take a relative endpoint (e.g. new Uri("/", UriKind.Relative)? Maybe we just need to relax the validation in the setter rather than making it completely nullable.

Also, while it does demonstrate the motivation for this change, I don't think we're ready to take on the maintenance of a Blazor + Aspire sample. If anything, I'd want to consolidate the samples, but that should be done after discussing what we can combine.

Rather than making the Endpoint fully optional, could we make it take a relative endpoint (e.g. new Uri("/", UriKind.Relative)? Maybe we just need to relax the validation in the setter rather than making it completely nullable.

If that's more viable, then sure.

Also, while it does demonstrate the motivation for this change, I don't think we're ready to take on the maintenance of a Blazor + Aspire sample. If anything, I'd want to consolidate the samples, but that should be done after discussing what we can combine.

Totally. I wanted to illustrate with a full e2e sample of what I am trying to do, but to do that it required changes in the underlying library so it was easier to do it in the repo. If this progresses forward, I would radically simplify the sample so there's not so many additional pieces in there.

Thanks for your contribution, but as I mentioned in my last comment, we don't want to maintain another sample for this. This does show there are scenarios where supplying an URL to the transport could be made optional, it's rare, and I think it's better to keep it required for documentation purposes. You can come up with a valid URI if you really need to even with the Aspire scenario.